Subject: "Steven H. Berl": APPN ISR over ATM

From: "Steven H. Berl" <[email-masked]>
Date: Wed, 11 Oct 1995 09:53:37 -0700

Hello, anyone home? No comments? Maybe it didn't get through.

Steve Berl
Cisco Systems, Inc.

------- Forwarded Message

Date: Wed, 27 Sep 1995 14:51:12 -0400
From: "Steven H. Berl" <[email-masked]>
To: [email-masked]
Subject: APPN ISR over ATM

Since this is not really an HPR issue, I have carbon copied this
e-mail to the aiw-appn-reference mailing list.

In the ATM-01 document section 1.2.3 entitled "Native ATM DLC", in the
secod to last paragraph, it is stated that:

      "Because HPR is a prerequisite for the native ATM architecture
      described in Chapter 2, "Native ATM DLC", the native ATM architecture
      does not support APPN/ISR FID2 traffic. Likewise, it cannot be used
      for links between DLUR nodes and down-stream nodes with dependant LUs.
      Additional architectural definition is required for such
      configurations. For example, an LLC such as IEEE 802.2 type 2
      providing error recovery must be specified."

In the ATM Forum Technical Committee, a contribution has been
submitted by IBM entitled "Multiprotocol over ATM Adaptation Layer
Type 5 Implementation Agreement". This is ATM Forum/94-0615. This
document describes the encapsulation of 802.2 type 2 traffic for
APPN/ISR FID2 traffic, as well as several other types of SNA traffic.

This sounds like the "additional architectural definition" refered to
in the ATM-01 document. I propose that this be accepted as part of
the APPN architecture as a standard DLC for transporting non-HPR
SNA traffic over and ATM network. 

Our implementation experience has shown that running LLC2 native over
ATM has value. 

- - It was extremely easy to implement. It is very similar to
  LLC2 native over Frame Relay.

- - In low error rate environments the lack of selective retransmission
  has not been an issue because one very rarely needs to retransmit anything.

- - There are a lot of people around who already have a good
  understanding of LLC2 and are able to look at decoded line traces,
  etc. (How many ATM line analyzers are available today that can
  decode RTP?) 

Of course, HPR traffic should be handled using all the extensions and
services presented in the ATM-01 document proposals. For the near
term, it would be good to accept the existing ATM Forum standard for
APPN ISR over ATM.

Steve Berl
Cisco Systems, Inc.

------- End of Forwarded Message

---

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 13 Oct 1995 15:37:00 -0400

>This sounds like the "additional architectural definition" refered to

The encapsulation format for the frames is the easiest, and therefore the
least important, aspect of supporting ISR traffic over ATM.  Of the 50 pages
in the IBM proposal presented at the last AIW only ONE addressed
encapsulation techniques, and it just says "See RFC 1483".

The much larger considerations addressed in this proposal are how to choose
a route through an ATM network, how to map APPN COS to ATM COS, how to
implement Connection Networks to select single hop paths through an ATM
network, and where we, the AIW, would like to see the ATM vendors deliver
functionality.

There is clearly nothing to prevent anyone from implementing an ATM data
link layer for ISR.  Since the RFC1483 and RFC1490 encapsulations are
aligned, for most implementations it will simply be inserting a mapping from
the Q.922 frame to the AAL5 format for ATM.  However it must be remembered
that our Frame-Relay implementations are only for PVCs.  Even if we extend
those implementations to support SVCs in a trivial way, we will not be
gaining the advantage of, for example, connection networks, for which there
is no architectural agreement.

The question before the AIW is therefore whether we wish to dilute our focus
by addressing the extension of COS mapping and Connection Networks into ATM
in both the ISR and HPR environments.

As a major vendor of equipment for public data networks for 2 decades Nortel
would LIKE to see Connection Networks supported in X.25 and Frame-Relay as
well as ATM.  As is well known in our community I have been trying to push
that for many years.  However can we AFFORD the dilution of effort?  I am 
afraid not.

As one technical issue:  LLC2 is designed for a medium with highly reliable
delivery and minimal end-to-end delay, that is LANs, particularly Token-Ring
LANs.  It has fixed transmission windows and fixed recovery timers.  It is
therefore not well suited to being transported over a WAN with potentially
large delays, comparatively poor reliability, and significant variation in
delay and throughput capacity.  Furthermore the smallest unit of
retransmission is a whole frame.  HPR has adaptive transmission windows and
variable recovery timers.  It is capable of retransmitting any set of bytes,
for example it could retransmit the contents of an individual ATM Cell if
necessary.  It is therefore ideally suited to be used over an ATM WAN.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |